Long Term Evolution (LTE)
Third-generation mobile systems (3G) based on WCDMA radio-access technology are being deployed on a broad scale all around the world. A first step in enhancing or evolving this technology entails introducing High-Speed Downlink Packet Access (HSDPA) and an enhanced uplink, also referred to as High Speed Uplink Packet Access (HSUPA), giving a radio-access technology that is highly competitive.
In a longer time perspective it is however necessary to be prepared for further increasing user demands and be competitive against new radio access technologies. To meet this challenge, 3GPP has initiated the study item Evolved UTRA and UTRAN, aiming at studying means for achieve additional substantial leaps in terms of service provisioning and cost reduction. As a basis for this word, 3GPP has concluded on a set of targets and requirements for a new mobile communication system which is called Long Term Evolution (LTE). LTE is designed to meet the subscriber and network operator needs for high speed data and media transport as well as high capacity voice support to the next decade.
LTE Architecture
The overall architecture is shown in FIG. 1 and a more detailed representation of the E-UTRAN architecture is given in FIG. 2.
The E-UTRAN consists of eNodeBs, providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the user equipment (UE). The eNodeB (eNB) hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC) and Packet Data Control Protocol (PDCP) layers that include the functionality of user-plane header-compression and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. It performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated uplink Quality of Service (QoS), cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of downlink/uplink user plane packet headers. The eNodeBs are interconnected with each other by means of the X2 interface.
The eNodeBs are also connected by means of the S1 interfaces to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME and to the Serving Gateway (SGW) by means of the S1-U. The S1 interfaces support a many-to-many relation between MMEs/Serving Gateways and eNodeBs.
The SGW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and PDN GW). For idle state user equipments, the SGW terminates the downlink data path and triggers paging when downlink data arrives for the user equipment. It manages and stores user equipment contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
The MME is the key control-node for the LTE access-network. It is responsible for idle mode user equipment tracking and paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the SGW for a user equipment at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the HSS). The Non-Access Stratum (NAS) signalling terminates at the MME and it is also responsible for generation and allocation of temporary identities to user equipments. It checks the authorization of the user equipment to camp on the service provider's Public Land Mobile Network (PLMN) and enforces user equipment roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signalling and handles the security key management. Lawful interception of signalling is also supported by the MME. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN. The MME also terminates the S6a interface towards the home HSS for roaming user equipments.
The control signalling between a mobile node (MN or also referred to as User Equipment UE) and the Radio Access is done by Radio Resource Control (RRC) messages. The RRC protocol is located in Layer 3 and provides functions for UE specific signalling, paging of idle mode UEs and system information broadcast. The RRC layer also supports retransmission functions to assure the correct transmission of control information of higher layers (e.g. NAS).
FIG. 3 shows a control-plane protocol stack between the UE and the MME for an exemplary LTE system. Layer 2 may be split in Medium Access Control (MAC), Radio Link Control (RLC) and Packet Data Convergence Protocol (PDCP), wherein the RLC and PDCP sublayers are terminated in the eNodeB at network side. The NAS layer is terminated in the UE and MME. The service the RLC layer provides in the control plane between UE and eNodeB is called Signaling Radio Bearer (SRB). In the user plane, the service provided by RLC layer between the UE and the eNodeB is called a Radio Bearer (RB) or Data Radio Bearer (DRB).
Amongst others, higher layer, i.e. Non Access Stratum (NAS), messages are carried by the RRC messages (e.g. using RRC Direct Information Transfer message) between the user equipment and the eNodeB. The Non Access Stratum is a functional layer running between the UE and the Core Network (CN) and located above the RRC. Furthermore, the NAS is the functional grouping of protocols aimed at Call Control (CC) for circuit switched voice and data, at Session Management (SM) for packet switched data and Mobility Management (MM) and at Short Message Services (SMS) for packet switched and circuit switched domains. The control messages the NAS layer generates are called NAS messages. Such messages are for example used to control Mobility Management, Session Management, SMS Transport and Call Management. NAS messages are transported transparently through the Access Stratum layers (layers 3-2-1, RRC, PDCP, RLC, MAC, PHY) that include the function and protocols to support the NAS transport.
The Access Stratum is the functional grouping of protocols specific to the access technique, in this case, the RRC, PDCP, RLC, MAC and PHY. It includes protocols for supporting transfer of radio-related information, for coordinating the use of radio resources between UE and access network, and for supporting access from the serving network to the resources provided by the access network. The Access Stratum offers services through Service Access Points (SAP) to the Non-Access Stratum (CN-related signaling and services), i.e. provides the Access Link between UE and core network, which consists of one or more independent and simultaneous UE-core network radio access bearer services, and only one signaling connection between the upper layer entities of UE and the core network.
After a non-access stratum signalling connection is established between the user equipment and the MME, e.g. due to service request procedure when data has to be transmitted, the user equipment and the MME enter the CONNECTED state. Initial uplink non-access stratum messages that initiate a transition from IDLE to CONNECTED state are Attach Request, Tracking Area Update Request, Service Request (or Extended Service Request) or Detach Request. In order to send the initial non-access stratum message, the user equipment first establishes a Radio Resource Control (RRC) connection to the eNodeB over the air interface (Uu interface). During the RRC connection establishment the user equipment and eNodeB get synchronized and establish the Signalling Radio Bearers (SRB) that can be used for the transport of the non-access stratum messages. This will be explained in more detail later with reference to FIG. 5.
FIG. 4 discloses the E-UTRAN user-plane protocol stack between UE, eNodeB, Serving-Gateway and PDN-Gateway. The protocol stack consists of the PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), and MAC (Medium Access Control) sublayers which are terminated in the eNodeB on the network side. An IP packet for a UE is encapsulated in an EPC-specific protocol and tunneled between the PDN-GW and the eNodeB for transmission to the UE.
EPS Mobility and Connection Management States
When a mobile terminal (or user equipment, UE) is attached to the network, the UE is in the so called REGISTERED state, i.e. EPS Mobility Management (EMM) context has been established and a default EPS bearer context has been activated in the network and in the UE. When the UE is REGISTERED to mobile network, the UE can be in two different connections management states: IDLE and CONNECTED state. When the UE is switched-off or not attached to the mobile network, the UE is in DEREGISTERED state. In DEREGISTERED state, no EMM context exists and the UE location is unknown to an MME and hence it is unreachable by an MME.
The UE is in IDLE state when there is no data for transmission and the radio resources are released, but the UE still has a valid IP configuration. A UE in IDLE state doesn't have a radio association (i.e. Radio Resource Connection, RRC) with the eNB, and therefore, there are no established signalling and data radio bearers. Further, there is no Non-Access Stratum (NAS) signalling connection between the UE and the network (e.g. to the MME) and also, there is no S1-U connection between the eNB and the SGW.
When the UE is in CONNECTED state and the network (usually the eNB) detects that the UE is not sending/receiving data for a certain period of time, the network (usually the eNB) decides to release the radio resources and the S1 connection. As a result, the UE transits from CONNECTED to IDLE state. Also the MME changes its internal state for the UE to IDLE and informs the SGW to release the S1-U connection to the eNB.
When uplink or downlink data or signalling (NAS signalling, e.g. due to the TAU procedure with active flag) needs to be exchanged between the UE and the network, the UE and the MME shall enter the CONNECTED state. It is possible in case of TAU procedure without active flag that the UE sends and receives respectively a single NAS message without entering the CONNECTED state. In order to transfer to CONNECTED state, the UE firstly needs to establish a Radio Resource Control (RRC) connection to the eNB over the Uu interface. During the RRC connection establishment the UE and eNB get synchronized and establish the Signalling Radio Bearers (SRB) and Data Radio Bearers (DRBs) that can be used for the transport of the NAS messages and uplink and downlink data.
The above described IDLE and CONNECTED states are related to the NAS layer state diagram. On the other hand, in the AS layer the IDLE and CONNECTED states are also defined. The AS IDLE and CONNECTED states are similar but not completely analogical to NAS IDLE and CONNECTED states, i.e. if the RRC connection is established, the AS state is CONNECTED, otherwise if the RRC connection is released, the AS state is IDLE. Not always when the AS state is CONNECTED, the NAS state is also CONNECTED (e.g. for TAU procedure without active flag). The establishment of the RRC connection, and thus, the transition to AS CONNECTED state, is initiated by the UE, as only the UE can send “RRCConnectionRequest” message. The UE initiates the RRC connections establishment either due to the availability of uplink data or uplink signalling; or due to paging from the network in order to receive downlink data or downlink signalling. Below there are more details about the 2 cases:                If the UE has uplink data or uplink ESM NAS signalling to send, the UE initiates the NAS Service Request procedure (described in the technical Standard TS 23.401 incorporated herein by reference). The UE generates a Service request message and triggers the AS to establish a corresponding RRC connection. The RRC establishment cause sent to the eNB in the “RRCConnectionRequest” message is set to “mo-Data” (mobile originated-data, meaning the UE would like to send uplink data) or “mo-Signalling” (mobile originated-signalling, meaning the UE would like to send uplink signalling).        If the network has downlink data or downlink NAS signalling to the UE, the network initiates the Paging procedure as described in Technical Specification TS 36.413 and TS 36.331, incorporate herein by reference. When the UE receives the paging, the UE initiates the NAS Service Request procedure by generating a Service request message to the MME. The Service request message triggers the AS layer to establish an RRC connection with the eNB. The RRC establishment cause is set to “mt-Access”which means Mobile Terminated access, i.e. mobile terminated communication is to be set up.        
The NAS Mobility Management (MM) and Session Management (SM) signalling in LTE/SAE are usually called EMM (EPS MM) and ESM (EPS SM) signalling. In contrary, in the UTRAN/UMTS the NAS signalling between the UE and SGSN is called GPRS Mobility Management (GMM) and GPRS Session Management (GSM) signalling. The terminology of EMM/ESM vs. GMM/GSM is introduced because for some aspects of this invention it is important to notice the difference between the SAE/LTE and UTRAN/UMTS systems. Depending on the ‘PS’ (packet switched domain) or ‘CS’ (packet switched domain) indication in the paging message, the UE can send either Service request message or Extended Service Request message for establishing the NAS connection. In the following the format and content of an Extended Service Request message, according to Chapter 8.2.15 of the Technical Specification TS 24.301 is shown.
InformationIEIElementType/ReferencePresenceFormatLengthProtocolProtocolMV½discriminatordiscriminator9.2Security headerSecurityMV½typeheader type9.3.1Extended serviceMessage typeMV1request message9.8identityService typeService typeMV½9.9.3.27NAS key setNAS key setMV½identifieridentifier9.9.3.21M-TMSIMobile identityMLV69.9.2.3B-CSFB responseCSFB responseCTV19.9.3.557EPS bearerEPS bearerOTLV4context statuscontext status9.9.2.1RRC
The RRC protocol supports the transfer of NAS information. In addition, for UEs in RRC_IDLE, RRC supports notification from the network of incoming calls. RRC connection control covers all procedures related to the establishment, modification and release of an RRC connection, including paging, initial security activation, establishment of Signalling Radio Bearer and of radio bearers carrying user data (Data Radio Bearers).
Dedicated RRC messages are transferred across Signalling Radio Bearers, which are mapped via the PDCP and RLC layers onto logical channels-either the Common Control Channel (CCCH) during connection establishment or a Dedicated Control Channel (DCCH) in RRC_CONNECTED. System information and paging messages are mapped directly to logical channels, the Broadcast Control Channel (BCCH) and Paging Control Channel (PCCH) respectively.
The main difference between SRB1 and SRB2 is the priority handling in the eNB, i.e. RRC messages sent over SRB2 have lower priority than the RRC messages sent over SRB1. Usually, the NAS Transport messages are carried over the SRB2 (as Uplink/Downlink Information Transfer messages); however, initial NAS messages, e.g. Service Request, can be piggybacked to the RRC messages carried over SRB1. Please note that the RRC messages over SRB1 contain control information for the RRC layer, whereas the RRC messages over SRB2 are like transport messages for NAS messages.
SRB0 is used for RRC messages which use the CCCH; SRB1 is for RRC messages using the DCCH; SRB2 is for the (lower-priority) RRC messages using the DCCH which only include NAS dedicated information. Prior to SRB2 establishment, SRB1 is also used for RRC messages which only include NAS dedicated information. In addition, SRB1 is used for higher-priority RRC messages which only include NAS dedicated information.
All RRC messages using DCCH are integrity-protected and ciphered by the PDCP layer (after security activation). The RRC messages using CCCH are not integrity-protected.
FIG. 5 is a signalling diagram illustrating the RRC connection establishment procedure of the Signalling Radio Bearers SRB0, 1 and 2, also including the initial security activation. RRC connection establishment involves the establishment of the SRB1 and the transfer of the initial uplink NAS message. This NAS message triggers the establishment of the S1 connection, which normally initiates a subsequent step during which e-UTRAN activates AS-security and establishes SRB2 and one or more DRBs (corresponding to the default and optionally dedicated EPS bearers).
In particular, upper layers (e.g. NAS) in the UE trigger connection establishment (e.g. in response to paging). The UE checks if access is barred. If this is not the case, the lower layers in the UE perform a random access procedure and the UE starts a timer (known as T300) and sends the RRCConnectionRequest message. This message includes an initial identity (S-TMSI or a random number) and establishment cause.
If E-UTRAN accepts the connection, it returns the RRCConnectionSetup message that includes the initial radio resource configuration including SRB1. Instead of signalling each individual parameter, E-UTRAN may order the UE to apply a default configuration, i.e. a configuration for which the parameter values are specified in the RRC specification.
The UE returns the RRCConnectionSetupComplete message and includes the NAS message, an identifier of the selected PLMN (used to support network sharing) and, if provided by upper layers, an identifier of the registered MME. Based on the last two parameters, the eNodeB decides on the core network node to which it should establish the S1-connection. A NAS Service Request or Extended Service Request message is included in the RRCConnectionSetupComplete message.
The purpose of the Initial Context Setup procedure between the eNodeB and the MME is to establish the necessary overall initial UE Context including E-RAB context, the Security Key, Handover Restriction List, UE Radio capability and UE Security Capabilities etc. The procedure uses UE-associated signalling.
E-UTRAN sends the SecurityModeCommand message to activate integrity protection and ciphering. This message, which is integrity-protected but not ciphered, indicates which algorithms shall be used.
The UE verifies the integrity protection of the SecurityModeCommand message, and, if this succeeds, it configures lower layers to apply integrity protection and ciphering to all subsequent messages (with exception that ciphering is not applied to the response message, i.e. the SecurityModeComplete (or SecurityModeFailure) message).
E-UTRAN sends the RRCConnectionReconfiguration message including a radio resource configuration used to establish SRB2 and one or more DRBs. This message may also include information such as a piggybacked NAS message or measurement configuration. E-UTRAN may send the RRCConnectionReconfiguration message prior to receiving the SecurityModeComplete message. In this case, E-UTRAN should release the connection when one (or both) procedures fail.
The UE finally returns the RRCConnectionReconfigurationComplete message.
FIG. 5 also discloses the transmission of a NAS Service Request or NAS Extended Service Request message transmitted to the MME, using the RRCConnectionSetupComplete message and an S1-AP message. The user equipment starts the timer T3417 or T3417ext as described in Technical Specification TS 24.301, section 5.6.1. The user equipment stops these timers T3417 or T3417ext when an indication from the Access Stratum is received accordingly. For instance, the user equipment shall receive the bearer establishment for user plane indication from the Access Stratum in order to stop timer T3417. To stop the timer T3417ext, the user equipment shall receive the system change indication from the Access Stratum.
Paging
To receive paging messages from E-UTRAN, UEs in idle mode monitor the PDCCH channel for an RNTI (radio network temporary identity) value used to indicate the paging: the P-RNTI. The UE needs to monitor the PDCCH channel only at certain UE-specific occasions. At other times, the UE may apply DRX (Discontinued Reception), meaning that it can switch off its receiver to preserve batter power.
In order to re-establish a connection towards a UE in idle mode, the MME distributes a paging request to the relevant eNodeBs, based on the tracking areas where the UE is expected to be located. When receiving the Paging Request message, the eNodeB sends a page over the radio interface in the cells which are contained within one of the tracking areas provided in that message. The UE is normally paged using its SAW-Temporary Mobile Subscriber Identity (S-TMSI).
The Paging Request message sent from the MME to the eNodeB is defined in the Technical Specification TS 36.413 Chapter 9.1.6 (incorporated herein by reference), as follows.
IE typeIE/GroupandSemanticsAssignedNamePresenceRangereferencedescriptionCriticalityCriticalityMessageM9.2.1.1YESignoreTypeUE IdentityM9.2.3.10YESignoreIndex valueUE PagingM9.2.3.13YESignoreIdentityPagingO9.2.1.16YESignoreDRXCN DomainM9.2.3.22YESignoreList of TAIs1YESignore>TAI List1 toEACHignoreItem<maxnoofTAIs>>>TAIM9.2.3.16—CSG Id List0 . . . 1GLOBALignore>CSG Id1 to9.2.1.62—<maxnoofCSGId>PagingO9.2.1.78YESignorePriority
The Paging message transmitted from the eNodeB to the user equipment is defined in Technical Specification 36.331 (incorporated herein by reference).
Short Message Service (SMS)
The Short Message Service (SMS) was intended in the beginning of the GSM standardization as a mechanism to send Short Messages from the network operator to the UE for configuration of the user equipment and information services (e.g. to inform about new prices or new tariff plans). Later, the Short Message service was specified to carry messages between the users (mobile-to-mobile text messages), as the service is of the type store-and-forward. The maximum SMS size is specified to 140 bytes, or 160 seven-bit characters, in order to fit into existing signalling formats at that time. Larger content can be sent in concatenated SMSs, where each SMS will start with a user data header (UDH) containing segmentation information. Since UDH is part of the payload, the number of available characters per segment is lower: 153 for 7-bit encoding (instead of 160 characters).
FIG. 12A shows the architecture for SMS transport in a mobile network. For simplicity the SM-SC, SMS-GMSC and SMS-IWMSC can be implemented in the same box and may be referred to as SM-SC. The SM service is regarded as circuit-switched service, and thus, the SMS is delivered from the SM-SC to the Mobile Switching Center (MSC) of the circuit-switched domain.
Two types of SMS are specified: mobile-originated (MO, sent in the uplink from the user to the network) and mobile-terminated (MT, sent in the downlink from the network to the user).
The protocol layered model of the SMS communication can be seen in FIG. 13, and will be explained in the following. The abbreviation “SM” used in this figure means “Short Message”.
It should be noted that FIG. 13 mainly discloses the protocol stacks for native SMS support in MME/SGSN. In other words, the protocol layer model for SMS communication using “SMS over SGs” is not depicted and different from the one of FIG. 13.
In FIG. 13 the shown SM-SC node may implement the functional entities SMS gateway MSC (SMS-GMSC) and SMS Interworking MSC (SMS-IWMSC) as it was already depicted in FIGS. 12A and 12B. The SMS-GMSC is used e.g. to connect to the serving MSC/SGSN for MT-SMS, i.e. the SMS-GMSC sends the MAP message containing the MT TPDU to the MSC/SGSN (such a MAP message is called MAP_MT_FORWARD_SHORT_MESSAGE carrying the TPDU or shortly “mt-ForwardSM(TPDU)”). The SMS-IWMSC is used e.g. to connect to the serving MSC/SGSN for MO-SMS, i.e. the serving MSC/SGSN sends the MAP message containing the MO TPDU to the SMS-IWMSC (MAP_MO_FORWARD_SHORT_MESSAGE carrying the TPDU or shortly “mo-ForwardSM(TPDU)”).
Please note that the implementation of the SMS protocol entities (e.g. SMR and SMC entities) as shown in FIG. 13 is an example. In future systems or systems other than 3GPP the implementation of the SMS functional entities may be done in physical nodes different from the depicted ones.
Regarding a MT-SMS, the SM-SC prepares in the Short Message Transfer Layer (SM-TL) the MT-SMS for sending. The SM-TL message (TPDU, Transfer Packet Data Units) is received in the Short Message Relay (SMR) Entity of the Short Message Relay Layer (SM-RL). The Packet Data Units (PDU) of the SM-RL layer are called RPDU (Relay Layer PDU). The MT-SMS itself is encapsulated in the RP-DATA RPDU, and the corresponding Acknowledgement or Error messages are called RP-ACK or RP-ERROR. Consequently, there are three kinds of RPUDs.
The SM-TP and the SM-RP protocols are implemented correspondingly in the SM-SC and MSC/MME on the network side and in the UE. Thus, the SMR entities implementing the Relay protocol are implemented in the MSC/MME and UE and exchange RPDUs among themselves.
In case of the classic transmission of SMS over the circuit-switched domain the SM-SC is usually connected to the MSC, and the MSC with the SGSN/MME through MAP/SS7 signalling. As explained later, In the future there will be a direct interface between the SM-SC and SGSN/MME for transmission of the SMS when the UE is attached to the packet-switched domain only, in addition or as an alternative. The SS7 signalling is part of the MAP protocol that is used to carry the TPDUs between the SM-SC and the SGSN/MME. SS7 signalling is actually used between the SM-SC and the Mobile Switching Center (MSC). The signalling over the direct interfaces between the SM-SC and SGSN or MME could be either based on MAP/SS7 signaling or based on IP specific protocols like DIAMETER.
When the TPDUs encapsulated e.g. in the MAP or DIAMETER protocols arrive at the serving MSC/SGSN/MME, the TPDUs are forwarded internally in the MSC/SGSN/MME's to the SMR entity and further to the SMC entity which is part of the Short Message Control Protocol (SM-CP) terminated in the UE and SGSN/MME in the Connection Management (CM) Sublayer. The protocol entities in this sublayer are called SMC (Short Message Control) entity. The PDUs exchanged at this sublayer are called CPDUs, which can be one of CP-DATA, CP-ACK and CP-ERROR. The CP-DATA PDU carries the RPDUs generated in the SMR entity. The CM sublayer can be considered as part of the NAS layer. The CM sublayer uses the services of the NAS Mobility Management (MM) sublayer. Depending on the 3GPP mobile system, the MM sublayer is called GMM (GPRS MM) or EMM (EPS MM). FIG. 14 illustrates an exemplary signalling flow for mobile originated (MO) SMS between the UE and the SM-SC for exchanging CPDUs and RPDUs. It is assumed that the UE is initially in IDLE mode. When the SMR entity in the UE generates an RP-DATA RPDU, the SMR entity triggers the SMC entity to establish a CM signalling (i.e. NAS) connection to the SGSN/MME.
In order to establish the NAS MM connection between UE and MME and the RRC connection between the UE and eNB, the UE sends a NAS Service Request message to the MME. Furthermore, the NAS layer in the UE requests the RRC layer to establish the RRC connection. After the RRC connection is established and the Service Request is transmitted, usually the Data Radio Bearer(s) are established, and the RRC layer indicates the NAS layer that the NAS MM connection is established. Afterwards the NAS MM layer informs the SMC entity about the established NAS MM connection and the SMC entity can sent and receive CPDUs.
After the NAS signalling connection is established, the SMC entity sends the CPDU CP-DATA containing the RP-DATA to the SMC entity in the SGSN/MME. The SMC entity forwards the RP-DATA to the SMR entity which encapsulates the RP-DATA into a TPDU. After internal forwarding, the SGSN/MME's MAP entity forwards the RP-DATA encapsulated in TPDU as a mo-ForwardSM (TPDU) to the MAP entity in the SM-SC.
The SMC entity in the SGSN/MME acknowledges the reception of CP-DATA with a CP-ACK message. When the SMC entity in the SGSN/MME receives an RPDU (e.g. RP-ACK) from the SMR entity, the SMC entity generates a CP-DATA CPDU containing the RPDU and transmits it to the SMC entity in the UE. When the SMR entities (in both UE and MME) do not have any more RPDUs to send, the SMR entity informs the SMC entity that the CM signalling connection is not any longer needed by sending a release request (Rel Req). In other words, the release of the CM connection (which could result in NAS MM connection release) is controlled by the SM-RL (with the exception of error situations).
In more detail, when the SMC entity in the MME/SGSN receives both the Rel Req from the SMR entity and the last CP-ACK from the UE, the SMC entity triggers the MM entity to start NAS MM connection release. For that purpose the MM entity in the MME/SGSN sends to the eNB a UE CONTEXT RELEASE COMMAND. In consequence the MME's MM entity transfers to IDLE state for that UE (but keeps the EMM and ESM context for that UE). On the other side, the eNB deletes the UE context and sends “RRC Connection Release” message to the UE. After reception of this message, the RRC layer in the UE indicates to the NAS layer that the RRC connection was released and the NAS layer transfers to IDLE state.
Similar signalling procedures are performed for mobile terminated (MT) SMS, as depicted in FIG. 15. In this case, the initial MT-SMS is encapsulated in a TPDU forwarded from the SM-SC towards the UE. When the mt-FSM carrying the TPDU arrives at the SGSN/MME, the message is internally processed and forwarded to SMR entity and to the SMC entity that triggers the establishment of a NAS MM signalling connection. To said end, the SGSN/MME pages the UE, and the UE responds with a Service Request message to initiate the Service Request procedure. Once the NAS MM connection is established, the SGSN/MME's SMC entity can send the CP-DATA CPDU containing the RP-DATA of the SMR layer to the UE. The UE's SMC entity processes the CP-DATA message and forwards the RP-DATA to the SMR entity. The SMC entity then sends the corresponding CP-ACK message to the SGSN/MME.
The SMR entity of the UE sends an RP-ACK message down to the SMC entity, which in turn puts the RP-ACK within a CP-Data CPDU and transmits same to the SMC entity in the SGSN/MME. When the SMR entity of the UE and/or the MME has no more RPDUs to send, it sends a release request message to its corresponding SMC entity to inform it that the CM connection is not any longer needed.
FIG. 16 illustrates in a more comprehensive way the signalling diagrams of FIG. 14 and FIG. 15 for the MO and MT SMS. Specifically, in the upper part the signalling procedure for the MO SMS is depicted; in the lower part, the one for MT SMS.
SMS Transmission in the Packet Switched Domain
In most of the cases a current UE that uses voice services and IP services is attached to the mobile network for both circuit switched and packet switched services. The mobile network (e.g. UTRAN) can support circuit-switched services and packet-switched services at the same time; accordingly, the mobile node may attach to the UTRAN also for either or both of circuit-switched and packet-switched services. E-UTRAN was specifically designed to only support packet-switched services, and thus a UE in the E-UTRAN cannot attach to circuit-switched services. Nevertheless, also for UEs in LTE network SMS delivery is possible, as will be explained below.
In 3GPP terminology it is said that the UE is “EPS/IMSI attached” (used in LTE/SAE systems terminology) or “GPRS/IMSI attached” (used in GSM/UMTS systems terminology). The term IMSI relates to the CS services, and the terms EPS and GPRS relate to PS services. In general, network nodes or entities and their corresponding interfaces, being used for CS services, are said to belong to the CS domain; accordingly, network nodes or entities and their corresponding interfaces, being used for PS services, are said to belong to the PS domain.
FIG. 12B discloses an exemplary system architecture and the interfaces between entities involved in the SMS transmission; the architecture depicted in FIG. 12B is more recent than the one of FIG. 12A. When the UE is connected over the LTE access to the MME, the function “native SMS-in-MME” shall be specified making it possible to forward the SMS directly via the SGd interface between the SM-SC and the MME (called SGd in analogy to the already existing interface Gd between the SM-SC and the SGSN). The only interface currently not finally defined in the standard is the SGd interface between the SM-SC and the MME, though it has been already agreed to set up such an interface; for that reason the name “SGd” is written in quotation marks in FIG. 12B, and the interface between SMS-SC and MME might be named differently in the standard.
The transmission of an SMS, when the UE is registered with the SGSN via the GERAN (also called 2G) or via UTRAN (also called 3G) can be performed in two different ways, generally; either in the PS domain (i.e. SMS over Gd interface) or in the CS domain (i.e. SMS over D interface and via the MSC entity). FIGS. 25-28 illustrate in general the various routes possible for SMS delivery, involving the CS domain and/or PS domain. The particular case where the UE is registered to the SGSN via GERAN and UTRAN is depicted in FIGS. 27 and 28.
SMS in PS domain (also called SMS over Gd interface): the SGSN implements an SMS protocol stack for the SM-RP and SM-CP protocols, such that a native SMS transmission is possible between the SMS-SC and the SGSN over the Gd interface. In this context, native SMS transmission means that the serving node to which the UE is attached supports the SMS protocols SM-RP and SM-CP to form RP-DATA and CP-DATA PDUs. Correspondingly, the SMS-SC transmits the SMS to the SGSN via the Gd interface using the SM-TP protocol, and in turn the SGSN can forward the SMS via the Gb or lups interface to the UE respectively in the GERAN or UTRAN access using the SM-CP and SM-RP protocols. This is depicted in FIG. 27, and may be referred to as “native-SMS-in-SGSN” delivery. FIG. 27 also illustrates with dashed lines how the UE is paged by the SGSN, upon receiving the MT SMS from the SMS-SC.
When the mobile node is in the LTE network, the SMS may be transmitted via the “new” SGd interface between the SMS-SC and the MME, and from the MME to the UE via the S1 interface using the SM-CP and SM-RP protocols. This is depicted in FIG. 26, and may be referred to as “native-SMS-in-MME” delivery. FIG. 26 also shows with dashed lines how the UE is paged by the MME, upon receiving from the SMS-SC the MT SMS in the MME.
Accordingly, the SMS is delivered in the core network using the PS domain entities only in FIGS. 26 and 27; the CS domain is not used. Please note that in such case the UE is not required to have MSISDN number. Thus, the MO and MT SMS can be routed (and possibly stored) in the core network without the presence of MSISDN identifier, but instead another UE identifier, e.g. IMSI, can be used.
In the recent 3GPP activities it was specified that the SGSN indicates to the UE the support for “PS only” SMS by sending the “SMS supported” flag in NAS GMM accept messages. This is mainly performed for MO SMS transmission, where the UE knows that the MO SMS can be transmitted over the SGSN serving node (i.e. no need to connect to the MSC for SMS transmission). Also, this NAS GMM “SMS supported” indication from the SGSN indicates to the UE that the MT SMS can be transmitted directly from the SGSN to the UE. Further, please note that the UE having only PS domain services and capable of NAS based SMS indicates “SMS-only” to the SGSN during combined Attach/RAU procedures.
SMS in CS domain: In general, the transport of SMS in the CS domain can be accomplished by using the MSC server, which then can transmit the SMS to the UE in the UTRAN or GERAN respectively. This is illustrated in FIG. 28, where the SMS is delivered only in the CS domain; thus, it can be referred to as “SMS-over-CS”. The SMS-SC, when receiving an MT SMS, forwards same via the D interface to the MSC server. When the UE receives the paging, the UE may change to the CS domain (i.e. the UE registers with the MSC). The MSC server then can directly transmit the SMS to the UE via the SMS CP/RP protocol (see FIG. 28). FIG. 28 also depicts the possible paging routes when an MT SMS arrives at the MSC and the UE is registered at the SGSN. Paging is possible over the Gs interface, such that the MSC generates a paging message, forwards same to the SGSN to be broadcast in the UTRAN network. Alternatively, the MSC may directly page in the GERAN and UTRAN. Please note that SMS transport is not possible over Gs interface from the MSC to the SGSN.
SMS in combined PS+CS domain: The MSC server (and thus the circuit-switched domain) is also involved in case the SMS is exchanged via the MSC server and over the SGs interface with the MME using the MAP protocol. In this case, the UE being located in the LTE network, receives the SMS from the MME over the S1 interface using the NAS protocol encapsulating the SM-CP PDU, transporting the SMS. FIG. 25 shows this SMS delivery which may be referred to as “SMS-over-SGs”. FIG. 25 also illustrates the paging with dashed lines; upon receiving an MT SMS from the SMS-SC, the MSC transmits a paging to the MME over the SGs interface. The MME in turn pages the UE in its network.
It should be noted that for the UE registered with the MME there is no difference between exchanging the SMS via SGs interface (i.e. “SMS-over-SGs” from the MSC, as specified in release 9 of the standard), or using the “native SMS-in-MME” function (directly from the SM-SC, as specified in release 11 of the standard).
The MME shall support SMS procedures, including SMC and SMR functions, as well as usual combined EPS/IMSI procedures for “SMS-only”. Additionally, the MME:                provides a non-broadcasted LAI (Location Area ID) to the UE (which is needed in the UE in order to be correctly combined CS+PS attached);        indicates in the Attach/TAU Accept message that the IMSI attach is for “SMS-only”;        notifies the HSS that the MME is capable of SMS transfer without the need of establishing an SGs association with an MSC.        
When a PS-only attached UE is connected over 2G/3G (i.e. GERAN/UTRAN) access to the SGSN, the following is specified for the SMS transmission:                With respect to the interface between SGSN and HSS/HLR:                    The support of SMS service via PS domain NAS is optional and depends on the HSS subscription, SGSN support and UE indication.            If the subscriber data doesn't contain CS subscription, HSS indicates to the SGSN “PS-only-enforced”, SGSN doesn't perform combined GMM procedures and doesn't establish Gs association.            If HSS indicates to the SGSN “PS-only-enabled” and the SGSN supports NAS based SMS, the SGSN does not to establish Gs association.                        With respect to the interface between SGSN and UE:                    UE having only PS domain services and capable of NAS based SMS indicates “SMS-only” to the SGSN during combined Attach/RAU procedures.            SGSN indicates “SMS-Supported” to the UE during Attach/RAU procedures. UE with only PS domain services and NAS based SMS capability and when receiving “SMS-Supported” should not perform IMSI Attach/LAU procedures.                        
In summary, four different cases can be identified regarding which entities support the native SMS exchange functionality, influencing how an SMS can be transmitted in the network architecture depending on the SMS functionality implement in the different nodes and depending on the network configuration actually used.
SMS in SGSNSMS in MMEYESNOYESABNOCD
The expressions “SMS in SGSN” and “SMS in MME” mean that the SGSN respectively the MME implements SM-RP and SM-CP protocols, i.e. the SMS native transmission is supported.
FIG. 25-28 are marked with the different cases so as to indicate which route of SMS exchange is possible for which case. For instance, the route of exchange according to FIG. 25 is actually possible for all cases. In Case A, where the SGSN as well as the MME implement the SM-CP/RP protocols, all of the routes of FIG. 25-28 are possible. Which one is actually used depends e.g. on network configuration and the location of the UE. In more detail, the HSS/HLR will store the entity which shall serve the UE for the SMS delivery; for example, the MSC, MME or SGSN. Correspondingly, when an SMS arrives at the SMS-SC, the SMS-SC contacts the HSS/HLR to learn the SMS serving node for the mobile node. Thus, assuming the UE is located in the LTE network, even though the MME might be capable of native SMS exchange (i.e. has the corresponding SM-CP/RP protocols), the network configuration is such that the HSS informs the SMS-SC about the MSC; in this case, this native SMS capability of the MME is not exploited and thus the SMS is not transmitted via the SGd interface directly to the MME. Instead, the SMS-SC learns the address of the MSC associated with the UE and transmits the SMS over the D interface to the MSC for further forwarding, as explained already above (see FIG. 25).
Similarly, despite the SGSN being able to natively send SMS, the SMS-SC might be instructed by the HSS/HLR to also use the MSC server instead when the UE is located in UTRAN (see FIG. 28).
The four Cases and possible SMS delivery routes are summarized below.
Case A: native SMS transmission is possible in the PS domain (no MSC involvement), when the UE is registered with either the SGSN or the MME (over LTE or 2G/3G). In this Case A the UE can natively send and receive SMS, when registered with the SGSN or with the MME, according to FIGS. 26 and 27. However, also the routes for SMS delivery according to FIG. 25 and FIG. 28 are possible, if the network configuration requires the SMS-SC to involve the CS domain.
Problems or uncertainties can occur in the following situations:                1) during the handover between GERAN/UTRAN and LTE: it is not specified how the SMS PDU are forwarded        2) when ISR is activated, the routing of the MT SMS should be clarified as the SM-SC needs to know a single entity for SMS routing (SM-SC inquires the routing information from HLR/HSS).        
Case B: native SMS transmission over the MME is possible. Since the SGSN does not support native SMS transmission, the route according to FIG. 27 is not possible. Instead, when the UE is located in the UTRAN network, the SMS has to be exchanged according to the route of FIG. 28. Correspondingly, in this Case B, when the UE is located in the UTRAN, the SMS transfer is only possible over the CS domain.
Problems or uncertainties can occur if the network operator would like to avoid the use of CS domain entities, e.g. MSC. It is unclear how the SMS PDUs are delivered to/from the UE when the UE is connected over the GERAN and UTRAN accesses. Case C: native SMS transmission over the SGSN is possible. The MME does not support native SMS transmission, for which reason the route exchange according to FIG. 26 is not possible for Case C. Instead, when located in the LTE network, the UE needs to receive the SMS according to route of FIG. 25 for which the MSC server is involved.
Problems or uncertainties can occur if the network operator would like to avoid the use of CS domain entities, e.g. MSC. It is unclear how the SMS PDUs are delivered to/from the UE when the UE is connected over the LTE access.
Case D: When neither the SGSN nor the MME support the native SMS capability, the exchange according to FIGS. 26 and 27 is not possible. Correspondingly, the MSC server is always involved to transfer the SMS to the UE as illustrated in FIGS. 25 and 28. This case D is not very relevant for the present application, since no SMS transmission in the PS domain is possible.
Recently the 3GPP standardization decided to implement the transmission of an SMS for UEs that are subscribed and/or attached for PS-services only (PS-only); this is even though SMS is considered a circuit switched service, which usually would involve the mobile switching center (MSC) as explained above and illustrated in FIGS. 25 and 28.
As shown above, the MSC server is involved in the SMS transmission according to FIGS. 25 and 28. In case Case B, when the UE is located in UTRAN an SMS transmission without MSC server is not possible. Correspondingly, in Case C, when the UE is located in LTE, an SMS transmission without the MSC server is also not possible. This is however in contrast to the goal of having a PS-only exchange of SMS for the UE where the MSC is no longer involved.
Idle State Signaling Reduction (ISR) Functionality
3GPP defined an optimization for the case of IDLE mode mobility between the LTE and UTRAN/GERAN access, i.e. when the UE moves between the serving nodes MME and SGSN. This optimization is called IDLE mode signaling reduction (abbreviated as ISR) and allows that the UE does not initiate any signaling when changing between different radio access technologies (RATs). In the following, a brief summary of the ISR functioning will be given; a more detailed discussion of ISR can be found in Annex J of 3GPP TS 23.401 v11.1.0 which can be downloaded from the 3GPP server and which is incorporated herein by reference.
ISR aims at reducing the frequency of TAU and RAU procedures caused by UE reselection between E-UTRAN (LTE) and GERAN/UTRAN, which are operated together. Especially, the update signaling between UE and the network is reduced; but also the network internal signaling is reduced.
The dependency between 2G/3G and EPC is minimized at the cost of ISR-specific node and interface functionality. The idea behind ISR feature is that UE can be registered in UTRAN/GERAN RA at the same time it is registered in an E-UTRAN TA or list of TAs. The UE keeps the two registrations in parallel and runs periodic timers for both registrations independently. Similarly, the network keeps the two registrations in parallel, also ensuring that the UE can be paged in both the RA and the TAs it is registered in.
ISR support is mandatory for E-UTRAN UEs that support GERAN and/or UTRAN and optional for the network. ISR requires special functionality in both the UE and the network (i.e. in the SGSN, MME, Serving GW and HSS) to activate ISR for a UE. The network can decide for ISR activation individually for each UE. Gn/Gp SGSNs do not support ISR functionality.
ISR is activated at handover from LTE to 2G/3G, or 2G/3G to LTE, provided the S-GW supports ISR. When downlink data arrives at the S-GW, the S-GW sends a Downlink Data Notification (DDN) request to both serving nodes, SGSN and MME.
When ISR is activated this means the UE is registered with both MME and SGSN. Both the SGSN and the MME have a control connection with the Serving GW. MME and SGSN are both registered at HSS. The UE stores MM parameters from SGSN (e.g. P-TMSI and RA) and from MME (e.g. GUTI and TA(s)), and the UE stores session management (bearer) contexts that are common for E-UTRAN and GERAN/UTRAN accesses. In idle state the UE can reselect between E-UTRAN and GERAN/UTRAN (within the registered RA and TAs) without any need to perform TAU or RAU procedures with the network. SGSN and MME store each other's address when ISR is activated.
Implicit detach by one CN node (either SGSN or MME) deactivates ISR in the network. ISR is deactivated in the UE when the UE cannot perform periodic updates in time.
As explained before, a recently establish goal for standardization is to allow SMS delivery for PS-only, i.e. without involvement of the MSC server. However, when the mobile is IDLE and activates ISR, SMS delivery is not yet properly defined. Since the UE avoids RAU and TAU with activated ISR, the HSS does not know whether the UE is located in LTE or UTRAN. Consequently, the SMS-SC would get two addresses from the HSS, namely the ones of SGSN and MME. The SMS-SC would then have to multicast the MT SMS to SGSN and MME, which is however currently not possible, since the SMS-SC needs one specific target to which it transfers the SMS.
There is the need for procedures to deliver SMS when the UE is in IDLE state and has ISR activated.
When ISR is not activated for the UE, then the HSS always knows exactly in which network the UE is located and thus may inform the SMS-SC about the corresponding serving node, be it the MME or the SGSN.
Handover from LTE to UTRAN Radio Access
Above, a short description was given of UE mobility when the UE is in IDLE mode, using the ISR to avoid unnecessary signaling, and the problems resulting therefrom. A description of UE mobility when the UE is in CONNECTED mode follows, and in particular the inter-RAT handover from LTE to UTRAN. Chapter 5.5.2 of 3GPP TS 23.401 v11.1.0 gives a very detailed explanation of inter RAT handovers and are incorporated herewith by reference; Chapter 5.5.2.1 and 5.5.2.2. in particular refer to Inter RAT handovers between the E-UTRAN (LTE) and UTRAN. Chapter 5.5.2.1, being the one mainly relevant for the present application, will be summarized in the following as far as helpful for the understanding.
FIG. 26 illustrates the message exchange performed in the network for the preparation phase of the inter-RAT handover, and corresponds to Fig. 5.5.2.1.2-1 of TS 23.401. The various steps of FIG. 26 are explained in great detail in Chapter 5.5.2.1.2 of TS 23.401, and will be repeated in the following.    1. The source eNodeB decides to initiate an Inter-RAT handover to the target access network, UTRAN Iu mode. At this point both uplink and downlink user data is transmitted via the following: Bearer(s) between UE and source eNodeB, GTP tunnel(s) between source eNodeB, Serving GW and PDN GW.            If the UE has an ongoing emergency bearer service the source eNodeB shall not initiate PS handover to a UTRAN cell that is not IMS voice capable.        NOTE 1: The process leading to the handover decision is outside of the scope of this specification.            2. The source eNodeB sends a Handover Required (S1AP Cause, Target RNC Identifier, CSG ID, CSG access mode, Source to Target Transparent Container) message to the source MME to request the CN to establish resources in the target RNC, target SGSN and the Serving GW. The bearers that will be subject to data forwarding (if any) are identified by the target SGSN in a later step (see step 7 below). When the target cell is a CSG cell or a hybrid cell, the source eNodeB shall include the CSG ID of the target cell. If the target cell is a hybrid cell, the CSG access mode shall be indicated.    3. The source MME determines from the ‘Target RNC Identifier’ IE that the type of handover is IRAT Handover to UTRAN Iu mode. The Source MME initiates the Handover resource allocation procedure by sending a Forward Relocation Request (IMSI, Target Identification, CSG ID, CSG Membership Indication, MM Context, PDN Connections, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, Source to Target Transparent Container, RAN Cause, MS Info Change Reporting Action (if available), CSG Information Reporting Action (if available), UE Time Zone, ISR Supported, Serving Network) message to the target SGSN. The information ISR Supported is indicated if the source MME and associated Serving GW are capable to activate ISR for the UE. When ISR is activated the message should be sent to the SGSN that maintains ISR for the UE when this SGSN is serving the target identified by the Target Identification. This message includes all PDN Connections active in the source system and for each PDN Connection includes the associated APN, the address and the uplink Tunnel endpoint parameters of the Serving GW for control plane, and a list of EPS Bearer Contexts. RAN Cause indicates the S1AP Cause as received from source eNodeB. The old Serving Network is sent to target MME to support the target MME to resolve if Serving Network is changed.            The source MME shall perform access control by checking the UE's CSG subscription when CSG ID is provided by the source eNodeB. If there is no subscription data for this CSG ID or the CSG subscription is expired, and the target cell is a CSG cell, the source MME shall reject the handover with an appropriate cause unless the UE has emergency bearer services.        The source MME includes the CSG ID in the Forward Relocation Request when the target cell is a CSG cell or hybrid cell. When the target cell is a hybrid cell, or if there are one or several emergency bearers and the target cell is a CSG cell, the CSG Membership Indication indicating whether the UE is a CSG member shall be included in the Forward Relocation Request message.        The target SGSN maps the EPS bearers to PDP contexts 1-to-1 and maps the EPS Bearer QoS parameter values of an EPS bearer to the Release 99 QoS parameter values of a bearer context as defined in Annex E of TS 23.401.        Prioritization of PDP Contexts is performed by the target core network node, i.e. target SGSN.        The MM context contains security related information, e.g. supported ciphering algorithms as described in TS 29.274. Handling of security keys is described in TS 33.401.        The target SGSN shall determine the Maximum APN restriction based on the APN Restriction of each bearer context in the Forward Relocation Request, and shall subsequently store the new Maximum APN restriction value.            4. The target SGSN determines if the Serving GW is to be relocated, e.g., due to PLMN change. If the Serving GW is to be relocated, the target SGSN selects the target Serving GW as described under clause 4.3.8.2 of TS 23.401 on “Serving GW selection function”, and sends a Create Session Request message (IMSI, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane, PDN GW address(es) for user plane, PDN GW UL TEID(s) for user plane, PDN GW address(es) for control plane, and PDN GW TEID(s) for control plane, the Protocol Type over S5/S8, Serving Network) per PDN connection to the target Serving GW. The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface.            The target SGSN establishes the EPS Bearer context(s) in the indicated order. The SGSN deactivates, as provided in step 7 of the execution phase, the EPS Bearer contexts which cannot be established.            4a. The target Serving GW allocates its local resources and returns a Create Session Response (Serving GW address(es) for user plane, Serving GW UL TEID(s) for user plane, Serving GW Address for control plane, Serving GW TEID for control plane) message to the target SGSN.    5. The target SGSN requests the target RNC to establish the radio network resources (RABs) by sending the message Relocation Request (UE Identifier, Cause, CN Domain Indicator, Integrity protection information (i.e. IK and allowed Integrity Protection algorithms), Encryption information (i.e. CK and allowed Ciphering algorithms), RAB to be setup list, CSG ID, CSG Membership Indication, Source RNC to Target RNC Transparent Container, Service Handover related information). If the Access Restriction is present in the MM context, the Service Handover related information shall be included by the target SGSN for the Relocation Request message in order for RNC to restrict the UE in connected mode to handover to the RAT prohibited by the Access Restriction.            For each RAB requested to be established, RABs To Be Setup shall contain information such as RAB ID, RAB parameters, Transport Layer Address, and Iu Transport Association. The RAB ID information element contains the NSAPI value, and the RAB parameters information element gives the QoS profile. The Transport Layer Address is the Serving GW Address for user plane (if Direct Tunnel is used) or the SGSN Address for user plane (if Direct Tunnel is not used), and the Iu Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data in Serving GW or SGSN respectively.        Ciphering and integrity protection keys are sent to the target RNC to allow data transfer to continue in the new RAT/mode target cell without requiring a new AKA (Authentication and Key Agreement) procedure. Information that is required to be sent to the UE (either in the Relocation Command message or after the handover completion message) from RRC in the target RNC shall be included in the RRC message sent from the target RNC to the UE via the transparent container. More details are described in TS 33.401.        The Target SGSN shall include the CSG ID and CSG Membership Indication when provided by the source MME in the Forward Relocation Request message.        In the target RNC radio and Iu user plane resources are reserved for the accepted RABs. Cause indicates the RAN Cause as received from source MME. The Source RNC to Target RNC Transparent Container includes the value from the Source to Target Transparent Container received from the source eNodeB.        If the target cell is a CSG cell, the target RNC shall verify the CSG ID provided by the target SGSN, and reject the handover with an appropriate cause if it does not match the CSG ID for the target cell. If the target cell is in hybrid mode, the target RNC may use the CSG Membership Indication to perform differentiated treatment for CSG and non-CSG members. If the target cell is a CSG cell, and if the CSG Membership Indication is “non member”, the target RNC only accepts the emergency bearers.            5a. The target RNC allocates the resources and returns the applicable parameters to the target SGSN in the message Relocation Request Acknowledge (Target RNC to Source RNC Transparent Container, RABs setup list, RABs failed to setup list).            Upon sending the Relocation Request Acknowledge message the target RNC shall be prepared to receive downlink GTP PDUs from the Serving GW, or Target SGSN if Direct Tunnel is not used, for the accepted RABs.        Each RABs setup list is defined by a Transport Layer Address, which is the target RNC Address for user data, and the Iu Transport Association, which corresponds to the downlink Tunnel Endpoint Identifier for user data.        Any EPS Bearer contexts for which a RAB was not established are maintained in the target SGSN and the UE. These EPS Bearer contexts shall be deactivated by the target SGSN via explicit SM procedures upon the completion of the routing area update (RAU) procedure.            6. If ‘Indirect Forwarding’ and relocation of Serving GW apply and Direct Tunnel is used the target SGSN sends a Create Indirect Data Forwarding Tunnel Request message (Target RNC Address and TEID(s) for DL data forwarding) to the Serving GW. If ‘Indirect Forwarding’ and relocation of Serving GW apply and Direct Tunnel is not used, then the target SGSN sends a Create Indirect Data Forwarding Tunnel Request message (SGSN Address and TEID(s) for DL data forwarding) to the Serving GW.            Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the anchor point for the UE.            6a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW Address(es) and Serving GW DL TEID(s) for data forwarding) message to the target SGSN.    7. The target SGSN sends the message Forward Relocation Response (Cause, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control Plane, Target to Source Transparent Container, Cause, RAB Setup Information, Additional RAB Setup Information, Address(es) and TEID(s) for User Traffic Data Forwarding, Serving GW change indication) to the source MME. Serving GW change indication indicates a new Serving GW has been selected. The Target to Source Transparent Container contains the value from the Target RNC to Source RNC Transparent Container received from the target RNC.            The IE ‘Address(es) and TEID(s) for User Traffic Data Forwarding’ defines the destination tunnelling endpoint for data forwarding in target system, and it is set as follows:                    If ‘Direct Forwarding’ applies, or if ‘Indirect Forwarding’ and no relocation of Serving GW apply and Direct Tunnel is used, then the IE ‘Address(es) and TEID(s) for User Traffic Data Forwarding’ contains the addresses and GTP-U tunnel endpoint parameters to the Target RNC received in step 5a.            If ‘Indirect Forwarding’ and relocation of Serving GW apply, then the IE ‘Address(es) and TEID(s) for User Traffic Data Forwarding’ contains the addresses and DL GTP-U tunnel endpoint parameters to the Serving GW received in step 6. This is independent from using Direct Tunnel or not.            If ‘Indirect Forwarding’ applies and Direct Tunnel is not used and relocation of Serving GW does not apply, then the IE ‘Address(es) and TEID(s) for User Traffic Data Forwarding’ contains the DL GTP-U tunnel endpoint parameters to the Target SGSN.                            8. If “Indirect Forwarding” applies, the Source MME sends the message Create Indirect Data Forwarding Tunnel Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)), EPS Bearer ID(s)) to the Serving GW used for indirect forwarding.            Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the anchor point for the UE.            8a. The Serving GW returns the forwarding parameters by sending the message Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for Data Forwarding). If the Serving GW doesn't support data forwarding, an appropriate cause value shall be returned and the Serving GW Address(es) and TEID(s) will not be included in the message.
FIG. 27 depicts the execution phase for the E-UTRAN to UTRAN Iu mode Inter-RAT handover as defined in TS 23.401, and corresponds to Fig. 5.5.2.1.3-1 of TS 23.401. The various steps of FIG. 27 are explained in great detail in Chapter 5.5.2.1.3 of TS 23.401, and will be repeated in the following.
The source eNodeB continues to receive downlink and uplink user plane PDUs.    1. The source MME completes the preparation phase towards source eNodeB by sending the message Handover Command (Target to Source Transparent Container, E-RABs to Release List, Bearers Subject to Data Forwarding List). The “Bearers Subject to Data forwarding list” IE may be included in the message and it shall be a list of ‘Address(es) and TEID(s) for user traffic data forwarding’ received from target side in the preparation phase (Step 7 of the preparation phase) when ‘Direct Forwarding’ applies, or the parameters received in Step 8a of the preparation phase when ‘Indirect Forwarding’ applies.            The source eNodeB initiates data forwarding for bearers specified in the “Bearers Subject to Data Forwarding List”. The data forwarding may go directly to target RNC or alternatively go via the Serving GW if so decided by source MME and or/target SGSN in the preparation phase.            2. The source eNodeB will give a command to the UE to handover to the target access network via the message HO from E-UTRAN Command. This message includes a transparent container including radio aspect parameters that the target RNC has set-up in the preparation phase. The details of this E-UTRAN specific signalling are described in TS 36.300.            Upon the reception of the HO from E-UTRAN Command message containing the Handover Command message, the UE shall associate its bearer IDs to the respective RABs based on the relation with the NSAPI and shall suspend the uplink transmission of the user plane data.            3. Void.    4. The UE moves to the target UTRAN Iu (3G) system and executes the handover according to the parameters provided in the message delivered in step 2. The procedure is the same as in step 6 and 8 in clause 5.2.2.2 in TS 43.129 with the additional function of association of the received RABs and existing Bearer Id related to the particular NSAPI.            The UE may resume the user data transfer only for those NSAPIs for which there are radio resources allocated in the target RNC.            5. When the new source RNC-ID+S-RNTI are successfully exchanged with the UE, the target RNC shall send the Relocation Complete message to the target SGSN. The purpose of the Relocation Complete procedure is to indicate by the target RNC the completion of the relocation from the source E-UTRAN to the RNC. After the reception of the Relocation Complete message the target SGSN shall be prepared to receive data from the target RNC. Each uplink N-PDU received by the target SGSN is forwarded directly to the Serving GW.    6. Then the target SGSN knows that the UE has arrived to the target side and target SGSN informs the source MME by sending the Forward Relocation Complete Notification (ISR Activated, Serving GW change) message. If indicated, ISR Activated indicates to the source MME that it shall maintain the UE's context and that it shall activate ISR, which is only possible when the S GW is not changed. The source MME will also acknowledge that information. A timer in source MME is started to supervise when resources in Source eNodeB and Source Serving GW (for Serving GW relocation) shall be released.            When the timer expires and ISR Activated is not indicated by the target SGSN the source MME releases all bearer resources of the UE. If Serving GW change is indicated and this timer expires the source MME deletes the EPS bearer resources by sending Delete Session Request (Cause, Operation Indication) messages to the Source Serving GW. The operation Indication flag is not set, that indicates to the Source Serving GW that the Source Serving GW shall not initiate a delete procedure towards the PDN GW. If ISR has been activated before this procedure, the cause indicates to the Source S GW that the Source S GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node.        Upon receipt of the Forward Relocation Complete Acknowledge message the target SGSN starts a timer if the target SGSN allocated S GW resources for indirect forwarding.            7. The target SGSN will now complete the Handover procedure by informing the Serving GW (for Serving GW relocation this will be the Target Serving GW) that the target SGSN is now responsible for all the EPS Bearer Contexts the UE has established. This is performed in the message Modify Bearer Request (SGSN Tunnel Endpoint Identifier for Control Plane, NSAPI(s), SGSN Address for Control Plane, SGSN Address(es) and TEID(s) for User Traffic for the accepted EPS bearers (if Direct Tunnel is not used) or RNC Address(es) and TEID(s) for User Traffic for the accepted EPS bearers (if Direct Tunnel is used) and RAT type, ISR Activated) per PDN connection. If the PDN GW requested UE's location and/or User CSG information (determined from the UE context), the SGSN also includes the User Location Information IE and/or User CSG Information IE in this message. If the UE Time Zone has changed, the SGSN includes the UE Time Zone IE in this message. If Serving GW is not relocated but the Serving Network has changed or if the SGSN has not received any old Serving Network information from the old MME, the SGSN includes the new Serving Network IE in this message. In network sharing scenarios Serving Network denotes the serving core network. If indicated, the information ISR Activated indicates that ISR is activated, which is only possible when the S GW is not changed. When the Modify Bearer Request does not indicate ISR Activated and S GW is not changed, the S GW deletes any ISR resources by sending a Delete Bearer Request to the other CN node that has bearer resources on the S GW reserved.            The SGSN releases the non-accepted EPS Bearer contexts by triggering the Bearer Context deactivation procedure. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL packet and does not send a Downlink Data Notification to the SGSN.            8. The Serving GW (for Serving GW relocation this will be the Target Serving GW) may inform the PDN GW(s) the change of for example for Serving GW relocation or the RAT type that e.g. can be used for charging, by sending the message Modify Bearer Request per PDN connection. The S GW also includes User Location Information IE and/or UE Time Zone IE and/or User CSG Information IE if they are present in step 7. Serving Network should be included if it is received in step 7 or in step 4 in clause 5.5.2.1.2 of TS 23.401. For Serving GW relocation, the Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers. The PDN GW must acknowledge the request with the message Modify Bearer Response. In the case of Serving GW relocation, the PDN GW updates its context field and returns a Modify Bearer Response (Charging Id, MSISDN, etc.) message to the Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context.            If PCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the RAT type.            9. The Serving GW (for Serving GW relocation this will be the Target Serving GW) acknowledges the user plane switch to the target SGSN via the message Modify Bearer Response (Cause, Serving GW Tunnel Endpoint Identifier for Control Plane, Serving GW Address for Control Plane, Protocol Configuration Options). At this stage the user plane path is established for all EPS Bearer contexts between the UE, target RNC, target SGSN if Direct Tunnel is not used, Serving GW (for Serving GW relocation this will be the Target Serving GW) and PDN GW.            If the Serving GW does not change, the Serving GW shall send one or more “end marker” packets on the old path immediately after switching the path.            10. When the UE recognises that its current Routing Area is not registered with the network, or when the UE's TIN indicates “GUTI”, the UE initiates a Routing Area Update procedure with the target SGSN informing it that the UE is located in a new routing area. It is RAN functionality to provide the PMM-CONNECTED UE with Routing Area information.            The target SGSN knows that an IRAT Handover has been performed for this UE as it received the bearer context(s) by handover messages and therefore the target SGSN performs only a subset of the RAU procedure, specifically it excludes the context transfer procedures between source MME and target SGSN.            11. When the timer started at step 6 expires, the source MME sends a Release Resources message to the Source eNodeB. The Source eNodeB releases its resources related to the UE.            When the timer started in step 6 expires and if the source MME received the Serving GW change indication in the Forward Relocation Response message, it deletes the EPS bearer resources by sending Delete Session Request (Cause, Operation Indication) messages to the Source Serving GW. The operation indication flag is not set, that indicates to the Source Serving GW that the Source Serving GW shall not initiate a delete procedure towards the PDN GW. The Source Serving GW acknowledges with Delete Session Response (Cause) messages. If ISR has been activated before this procedure, the cause indicates to the Source S GW that the Source S GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node.            12. If indirect forwarding was used then the expiry of the timer at source MME started at step 6 triggers the source MME to send a Delete Indirect Data Forwarding Tunnel Request message to the S GW to release the temporary resources used for indirect forwarding.    13. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at target SGSN started at step 6 triggers the target SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the target S GW to release temporary resources used for indirect forwarding.
Above, the currently used handover procedure for the Inter-RAT handover from E-UTRAN (LTE) to UTRAN was explained. Considering now the scenario in which the UE is in CONNECTED mode and currently receiving an SMS, when the UE performs a handover from the LTE to UTRAN, it is unclear how the SMS are further exchanged after the handover.
In more detail, considering a currently used route according to FIG. 26, after the UE handovers to the SGSN, and provided a PS-only delivery shall be ensured (route according to FIG. 28 not possible), it is not yet defined how the SMS can be exchanged. Similarly, considering a currently used route according to FIG. 27, and provided a PS-only delivery shall be ensured (route according to FIG. 25 not possible), it is not yet defined how the SMS can be exchanged.
Furthermore, in the LTE system at least the default bearer is established and activated, even though it is not used and only SMS transmission is performed between MME and UE over the NAS signaling connection. This is not the case for UTRAN, where a signaling may be established alone, independent from a data connection (data bearer), i.e. a data connection is not mandatory in UTRAN. In this case however, when handing over from E-UTRAN to UTRAN, the default bearer activated in E-UTRAN is automatically mapped to a corresponding PDN connection in UTRAN, even though it is not needed and not mandatory. It should be also noted that this problem exists not only for the Release 11, but already for Release 8 and 9 of the 3GPP standard; in particular for the cases of 1) SMS transmission over the SGs interface and of 2) CS fallback during SMS transmission over SGs (see also TS 23.272, section 8.2.5d).
The present application provides a solution to these problems.
Machine to Machine
The current mobile networks are optimally designed for Human-to-Human communications, but are less optimal for M2M (Machine-2-Machine) applications, which according to 3GPP is also termed MTC (Machine-Type-Communication).
M2M Communication can be seen as a form of data communication between entities that do not necessarily need human interaction. It is different to current communication models as it involves new or different market scenarios, lower costs and effort, a potentially very large number of communicating terminals and little traffic per terminal to a large extent.
Some MTC applications are for example:                Security (e.g. Alarm Systems, Backup for landline, Access Control, Car/Driver security)        Tracking & Tracing (e.g. Fleet Management, Order Management, Pay as you drive, Road Tolling, Traffic information)        Payment (Point of Sales, Vending machines, Loyalty Concepts, Gaming machines)        Health (Monitoring vital signs, Remote diagnostics, Web Access Telemedicine point)        Remote Maintenance/Control (Sensors, Lighting, Pumps, Valves, Elevator control)        Metering (e.g. Power, Gas, Water, Heating, Grid Control)        
A study item on M2M communications (3GPP TR 22.868) was completed in 2007. For Rel-10 and beyond, 3GPP intends to take the results on network improvements from the study item forward into a specification phase and address the architectural impacts and security aspects to support MTC scenarios and applications. As such, 3GPP has defined a work item on Network Improvements for Machine-Type Communication (NIMTC) with different goals and objectives such as to reduce the impact and effort of handling large machine-type communication groups, optimize network operations to minimize impact on device battery power usage, stimulate new machine-type communication applications by enabling operators to offer services tailored to machine-type communication requirements or provide network operators with lower operational costs when offering machine-type communication services.
The MTC has some specifics that are different from the usual human-to-human communication. 3GPP tries to identify these specifics in order to optimize the network operations. These specifics are called “MTC features” and are explained in the technical standard TS 22.368 available from http://www.3gpp.org and incorporated herein by reference. For example, one of the mentioned MTC feature can be “small data transmissions”, meaning that the MTC device sends or receives small amounts of data. Small amount of data means that the data is smaller or comparable with the size of the exchanged signalling needed to establish the data connection. The exact definition of “small data” is subject of the 3GPP standardization stage 1 and can be a part of the UE's subscription or by network operator policy. Furthermore, the MTC devices may be attached to or detached from the network, before transmission of a small amount of data.
The requirement for UEs subscribed or configured for “small data transmission” is to transmit the small amounts of data with minimal network impact (e.g. signalling overhead, network resources, delay for reallocation). The small data shall be efficiently transmitted in the uplink and in the downlink.
There could be several possible solutions to optimize the small data transmission:                The small data can be encapsulated in a usual Short Message Service (SMS). There are 3 main mechanisms to transmit SMS when the UE is attached to a packet switched (PS) EPS network:                    SMS over Circuit Switched Fall-back (CSFB) mechanism. The CSFB mechanism is explained in 3GPP TS 23.272. When there is SMS in the downlink the UE is paged from the network to attach to the circuit switched (CS) domain, i.e. either to the GERAN or the UTRAN access system. Since the MTC Devices are expected to be not expensive mobile devices, it is expected that they would implement only one radio access technology, and thus, would be no capable of CS and PS domain switching. Further, it is expected that many MTC Device would be PS only capable, so CSFB is not a possible general solution;            SMS over IP Multimedia Subsystem (IMS) mechanism. The IMS system is mainly designed for transport of voice and other real time services over IP using Session Initiation Protocol (SIP) and Session Description Protocol (SDP). As mentioned above, the MTC Devices are expected to be low cost device and the implementation of an IMS client could be expensive. Thus, SMS over IMS solution may not be always a desirable solution;            SMS over SGs mechanism. The SGs is the interface between the Mobile Switching Center (MSC) and the MME. The MSC constitutes the interface between the radio system and the fixed networks. It performs all necessary functions in order to handle CS services to and from the mobile stations. This is shown in FIG. 6 which is described below in detail.                        The small data is encapsulated in NAS transport messages, similar as SMS-o-SGs mechanism. The difference to SMS-o-SGs is that the small data is small IP packets that somehow are routed to the MME and then the MME encapsulates the IP packets in NAS packets.        
FIG. 6 is a signaling diagram depicting the transport of SMS using the SMS-o-SGs mechanism. It is assumed that the UE is configured for EPS services and for the feature of “SMS only”. “SMS only” means that the SMS (which is considered as Circuit Switched service) is transported over the LTE access system using SMS-o-SGs mechanism. For this purpose the UE and network exchange their capabilities regarding the SMS transport during the attach procedure. If both, the UE and the network implement SMS-o-SGs and agree to use this mechanism, then the UE's status in the MME is attached for PS services and “SMS-only”. Thus, when a downlink SMS arrives at the MME, the MME pages the UE with a “PS” indicator as describe above.
Furthermore, it is assumed that the UE is in an IDLE mode, thus does not have any radio resources configured for receiving or transmitting data.
In step (1), when an SMS with small data arrives at the MME, a paging message is transmitted to the UE in order to alert the UE that downlink data is to be received. The paging message may include a core network domain indicator set to “PS”, i.e. packet switched, which means that the user equipment is triggered to establish a connection to the EPS system via the LTE access technology.
In step (2) the user equipment responds with a service request message, starts the timer T3417 and waits for the establishment of the data radio bearers (DRBs). This service request message is one of the EPS mobility management messages and initiates the service request procedure. The purpose of the service request procedure is to transfer the EMM mode from EMM-IDLE to EMM-CONNECTED mode and establish the radio and S1 bearers when uplink user data or signalling is to be sent. Another purpose of this procedure is to invoke MO/MT (Mobile Terminated) circuit switched fallback procedures.
This procedure is used e.g. when the network has downlink signalling pending, when the UE has uplink signalling pending or when—the UE or the network has user data pending and the UE is in EMM-IDLE mode. The service request procedure is initiated by the UE, however, for the downlink transfer of signalling or user data in EMM-IDLE mode, the trigger is given by the network by means of the paging procedure.
No particular acknowledgment will be received by the UE for the service request message. Acknowledgment is thus provided by the establishment of radio bearers. The timer T3417 is terminated when the UE obtains an indication by the Access Stratum (AS) that the Data Radio Bearer (DRB) over the radio interface is established. The default value of the timer T3417 is 6 s. If the UE doesn't receive an indication from the AS before the timer T3417 expires, the user equipment retransmits the ServiceRequest message to the MME.
After the MME receives the ServiceRequest message from the UE, in step (3) the MME triggers the eNB to set up the data radio bearers between the UE and the eNB (see step 3.2). In particular, the MME triggers the S1-AP “Initial Context Setup” procedure towards the eNB to set up radio bearers (SRBs and DRBs), establish security protection over the radio interface, to configure the UE's context for the establishment of S1-U bearer and other functions. Furthermore, an RRCConnectionReconfiguration message is transmitted from the eNB to the UE, including configuration information for the one or more data radio bearer. The user equipment responds with an RRCConnectionReconfigurationComplete message after configuring the data radio bearers as instructed.
The data radio bearer(s) established between the user equipment and the eNodeB however are not used to transmit the small data. Instead, the small data is transmitted from the MME to the UE using the NAS protocol messages (see FIG. 3, illustrating that NAS terminates in UE and MME). In step (4) the SMS is encapsulated in a DOWNLINK NAS TRANSPORT message. The NAS exchange in general and the NAS transport in particular is performed when the UE is in CONNECTED mode, and thus, not only the SRBs but also the corresponding DRB(s) are established. Analogically, the S1-U bearers between the eNB and the S-GW are established as well.
As seen from above, a possible solution for transmitting small data is to use NAS protocol message between MME and user equipment. However, there are problems involved with this prior art solution.
For one thing, though the small data is transmitted using NAS messages, data radio bearers are established between the user equipment and the eNodeB. The reason is that the NAS Service Request message transmitted in step (2) triggers the establishment of the data radio bearers according to steps 3.1 and 3.2. In general, it should be noted that it is not efficient to send small data using EPS bearers, because the signalling overhead for constructing/keeping EPS bearers is large relative to the content size of small data. Furthermore, when the data radio bearers are not even used for small data transport, the signalling is in vain.
The establishment of the EPS bearers (i.e. DRBs and S1-U bearers) and the later release of those bearers consume signalling exchange between the involved nodes and also signalling processing in the nodes itself. Therefore, it is desirable to avoid the establishment of EPS bearers when the UE establishes RRC connection and transfers from IDLE to CONNECTED state.
It should be noted that in an UMTS system, when the user equipment is attached to the network, only context for the control plane is established in the UE and in the Core network (SGSN). When an IDLE UE transfers to CONNECTED state, first only the control plane connection is established, and later the UE initiates the PDP context activation for establishment of data bearers. To the contrary, in EPS system, at least one default EPS data bearer is established when the UE attaches to the network. Thus, when the user equipment transfers from IDLE to CONNECTED state, the EPS bearer (in user plane) is established in parallel to the control plane connection. Therefore, the specific problem targeted by this invention is how to avoid the establishment of user plane bearers when a user equipment attached to EPS system transfers from IDLE to CONNECTED state and the user equipment has already default EPS bearer context, but only small data over control should be transmitted.
Another possibility to transmit small data is to use the SMS procedure as explained in FIG. 14-16. Correspondingly, the SMS would be transmitted as RP-Data RPDU to or from the UE. If the small data is bigger then 140 bytes, the small data can be transmitted in a concatenated SMS consisting of multiple segments, i.e. SMS.
The release of the radio resources established for the SMS transport according to FIG. 14-16 may not be most advantageous as will be explained in the following.
Usually, for data transmission the eNB initiates to release the RRC connection established between the UE and the eNB, after an inactivity time i.e. when non packets transmission over the radio interface has been performed for a particular time. The eNB sends an S1-AP signalling to the MME to request the radio resource release. Then, the MME instructs the eNB to delete the UE-specific context which results in the RRC connection release.
When the UE's lower layers (i.e. access stratum) indicate RRC connection release, the UE releases the NAS signalling connection too.
It should be noted that the release of the RRC connection as described above, also means the transition from CONNECTED to IDLE state in the NAS layer for both the UE and the MME.
The signalling procedure for the release of the NAS MM signalling connection between the UE and the MME is initiated by the network, i.e. MME.
Concerning SMS transmission, the current 3GPP specification describes procedures for NAS mobility management connection release. One such example of NAS Mobility Management connection release is given below assuming a Mobile Terminated SMS. For MT SMS, the SMC entity in the UE has the following states: MT-Idle, MT-Wait for CO-Ack, and MT-MM-connection established. The SMC entity in the UE triggers the NAS Mobility Management layer for NAS connection release in some of the following cases:                When the SMC-entity in “MT-MM-connection established” state receives a CM-connection release request message from the SM-RL layer (SMR entity). For example, the CM-connection release request from the SM-RL layer can be indicated to the SMC entity when the SMR entity sends an RP-Ack to acknowledge the reception of an MT SMS;        When the SMC entity enters the MT-Idle state;        When an error occurs, e.g. in the SM-RL layer. For instance, this could happen when the Relay Layer does not receive from the Transfer Layer an indication to send the RP-Ack for the MT SMS.        
The NAS radio resource release procedure is initiated when the SMC entity in the MME receives the CP-Ack and the Release Request indication from the SM-SC. After the successful transmission of the small data, the quick release of the radio resources is advantageous in order to save capacity in the radio access network.
However, the quick release might not be beneficial at all times. It may e.g. lead to a consecutive re-establishment of the radio connection, e.g. when the UE has to transmit data in response to the SMS. For instance, the MT SMS may be used as a trigger for the MTC application to perform some actions, and in particular to send a data report (which could be one or more MO SMSs) or to establish data connection (i.e. EPS data bearer) to the MTC server. In these and other cases, if the NAS MM connection termination as described above is applied, then the UE would need to re-initiate the RRC connection to send the MO SMS or to establish the data bearers shortly after the connection was released. Put differently, the NAS MM connection, and also the RRC connection, might be terminated too early.